The present disclosure relates generally to stale message detection and, more specifically, to stale message detection in application protocols that use non-real-time transports.
As used herein, the terms “User Agent” and “UA” can refer to wireless devices such as mobile telephones, personal digital assistants (PDAs), handheld or laptop computers, IP phones, and similar devices or other user equipment (“UE”) that have telecommunications capabilities. In some embodiments, a UA may refer to a mobile, wireless device. The term “UA” may also refer to devices that have similar capabilities but that are not generally transportable, such as desktop computers, set-top boxes, or network nodes. Throughout this disclosure, UA may refer to a session initiation protocol (SIP) UA such as a wireless device, set-top box, or other communication devices and is interchangeable with the term UA.
When communicating using a wireless network, various Internet protocols (IP) can be implemented for allowing communication between a UA and a network. One example protocol, as defined in Third Generation Partnership Project (3GPP) systems, includes an internet protocol (IP) multimedia subsystem (IMS) that allows for the delivery of IP multimedia services. Using IMS, a UA may transmit and receive multimedia and/or voice packet switched (PS) communications via a base station implementing one or more IMS Functional Component. To implement IMS, networks rely upon SIP to provide a text-based signaling protocol that may be used to communicate between a UA and the IMS Core Network (CN), between the IMS CN and Application Servers, and between various other components of the IMS Network.
Generally, these protocols use a request-response communication strategy. As such, when communicating, messages such as request messages are sent by a first entity. The request messages are processed and response messages are then transmitted. The response messages generally include data responsive to the sent message. These combinations of sent messages and response messages allow for the communication of data and protocol states between a protocol Client and a protocol Server.
The following is an example of one such protocol. If a protocol Client (e.g. a Client entity, a User Agent Client (UAC) as described in “IETF RFC 3261 SIP: Session Initiation Protocol,” or a client UA) wishes to establish a session, the Client may send a request message (e.g. a SIP INVITE message) to a protocol Server. The message is received by a Server, and the Server (e.g. a Server entity, a User Agent Server (UAS) as described in “IETF RFC 3261 SIP: Session Initiation Protocol” or a server UA) replies to the request message with a response message that can contain a state of the processed request message and other protocol data. The Client receives the response message and processes the message accordingly. If the Client is configured to expect to receive a response message and does not receive a response within a particular time period, the Client may consider the original request as failed and report the failure to the requesting application.
In some cases, real-time communication protocols may be implemented using non-real-time transports. Non-real-time transports allow messages to be queued for delivery at a later time, but can be used as transports for real-time protocols that presume non-delayed processing and delivery of messages. In existing networks, an example real-time protocol includes IMS centralized services (ICS) that allows various IMS services to be provided to a UA using a wireless network where voice communications are provided over a circuit-switched (CS) bearer and other media components are provided over a packet-switched (PS) bearer. Generally, ICS requires the support of two real-time transport bearers: a bearer for voice, and a bearer to support the control signaling that uses SIP signaling. In some circumstances, however, the bearer for supporting SIP signaling may be unavailable, for example, because Gm connectivity does not exist (e.g., no PS roaming agreement exists or data connectivity is not available), the UA is unable to register with the IMS infrastructure because of operational issues, or dual transfer mode (DTM) is unavailable in the cell or the wireless device. In that case, the non-real-time I1 protocol transport is used instead and allows a wireless device to implement a SIP-like signaling protocol using a CS bearer in the place of the Gm interface. In that case, the I1 protocol uses or binds to transport protocols such as but not limited to short message service (SMS), unstructured supplementary service data (USSD), or proprietary protocols that make use of their own equipment and technology to queue the messages for later delivery. The use of these transport protocols, however, may result in significant delay (or potential failure) in the delivery of messages between a protocol client and a protocol server.
Because the transport protocol may include non-real-time interfaces (e.g., the I1 interface, or any other I1-like or SIP-like protocol, for example), the transport may insert significant delay into the delivery of a message. If the message is sufficiently delayed, the message may become stale meaning that the message should be discarded by the receiving entity because the message relates to services that are no longer requested or being used. For example, a protocol Client may send a request to a protocol Server using a non-real-time transport such as SMS. If the Server is out of coverage or turned off, the Server cannot immediately receive the message and respond accordingly. As a result, after failing to deliver the message directly to the Server, the SMS infrastructure stores the message for later delivery, possibly resulting in substantial delay between the Client's transmission of the request message and receipt of the message by the Server resulting in a communication failure.
Eventually, though, after the communication failure has already been reported by the Client to the requesting application, the protocol server will return to coverage and be powered-up. At that time, the SMS infrastructure detects that the Server is available and delivers the stale Client request to the Server. Upon receipt of the request message, the Server processes the request message and generates a response. The response message is then transmitted to the Client where it may be processed.
This protocol behavior may result in an unsatisfactory user experience. If, for example, the Client had originally issued a SIP INVITE message, after receiving the delayed request, the Server application may alert the user of an incoming call that is, in fact, several hours old. Furthermore, if a message is stale and should not be processed, communications protocols that attempt to process and respond to all messages, stale or not, create unnecessary traffic on the network in both wireless and fixed segments of the networks.